Feature SummaryMicrosoft Catapult Server provides:
With Catapult Server, clients can access the Internet through the Proxy service, the Remote Windows Sockets service, or both services working together.
The Catapult Server Proxy service:
The Remote Windows Sockets service:
The Proxy service used with the Remote Windows Sockets service:
Proxy Service Features
Proxy services are particularly appropriate for today's environment, in which the popularity and growth of the Internet has created a need for corporations, organizations, and schools to allow Internet access from client computers on their private network. At the same time, these entities need to isolate their private network from the Internet for a variety of reasons, including security, private addressing, and transport incompatibility. The Catapult Server Proxy service reconciles these potentially incompatible needs.
The Catapult Server Proxy service runs on a computer with two network adapter cards, one for each network to which it is connected. Typically, this computer is the only computer to which both networks are connected. The computer running the Catapult Server Proxy service thus serves as a gateway computer between the two networks. Larger networks may have multiple gateway computers, each running the Catapult Server Proxy service. The following figure shows a common scenario: the Catapult Server Proxy service provides an private network client with access to the Internet.
If both networks are running Transmission Control Protocol over Internet Protocol (TCP/IP), you should disable routing by clearing the Enable IP Routing checkbox in the Windows NT Server TCP/IP Advanced Configuration dialog box. Disabling this feature means that there can be no direct routing between the two networks: All information must pass through the Proxy service.
The Catapult Server Proxy service supports proxy requests from any browser that is compatible with the standard CERN proxy protocol, such as Microsoft Internet Explorer or Netscape. The browser can be on a computer running any operating system platform, such as Windows, Windows NT, Macintosh, or UNIX. The Catapult Server Proxy service requires no client-side components, because all client support needed for this standard protocol is built into all popular browsers.
The Catapult Server Proxy service includes such features as domain filtering, Internet resource caching, and client authentication. The new Secure Sockets Layer (SSL) tunneling protocol is also supported. SSL Tunneling allows a client to create a connection to a server through the proxy for encrypted data that cannot be interpreted by the proxy. This is used for SSL with the https protocol, and the secure news protocol, snews.
The Catapult Server Proxy service has built in request logging allowing log records to be written to a flat file or to a database via Open Database Connectivity (ODBC). This logging is separate from the logging built into the IIS Web service and includes proxy-specific information.
Your private network must run TCP/IP in order for browsers to communicate with the Catapult Server Proxy service. However, you can use the Catapult Server Proxy service in conjunction with Catapult Server Remote Windows Sockets component for IPX/SPX transport support. For more information, in this chapter see RWS Service Features, and Features of Proxy and RWS Services Together. Also see Appendix A, “Architecture.”
Catapult Server can be configured to allow anonymous requests by users, or to require users to be authenticated (validated) by the Proxy. Once users are authenticated, access control configuration determines which protocols (Web, FTP, or gopher) are accessible for each user. Users can be allowed access, or denied access, to each protocol.
Access control is integrated into Windows NT security and administration. The user accounts used for logon, or authentication, are created with User Manager, the standard User Account administration tool. Each Internet protocol (Web, FTP, gopher) is represented within Catapult Server by an object on which Access Control Entries (ACEs) can be applied, indicating which users have access to the protocol, and which users do not. Assignment of Access Control Entries is done in Internet Service Manager.
A convenient way to configure user-level access control is with Local Groups. With User Manager, an administrator can create groups, and add user accounts to these groups. Within Internet Service Manager, the site would assign Access Control to each group, as appropriate. For example, one group may have HTTP access only, and no FTP access. When a user joins, or leaves, no changes would be necessary in Internet Service Manager. The user account is simply added or removed from a group in User Manager.
Catapult Server supports two forms of user authentication: HTTP Basic authentication, and Windows NT Challenge/Response authentication. When using Basic authentication, the user sends a request, by entering a URL or clicking on a hyperlink. The proxy server responds with an ‘authentication failure’ message to the client, and typical clients typically display a user name/password dialog box in response. The user enters a valid user name and password, and the browser reissues the same request, but this time the header contains user information, which is used by the proxy server to authenticate the user.
In order for basic authentication to work with a proxy server, the browser being used must support the new ‘proxy-authenticate’ HTTP header. Internet Explorer 3.0 supports this. Earlier versions of Internet Explorer do not support this header, and therefore, do not support HTTP Basic Authentication through a proxy.
Basic authentication does not encrypt your user name and password before transmission. Basic authentication is encoded only by using UUencode, and can be decoded easily by anyone with access to your network, or to a segment of the Internet that transfers your packets.
Windows NT Challenge/Response authentication uses the same secure mechanism for Catapult Server logon that is used by clients logging onto a Windows NT-based computer. When this mechanism is used, the user needs to be logged onto the client computer, with a computer or domain user account that is valid on the computer running Catapult Server . When the user issues a request, the Windows NT Challenge/Response protocol is used between client and proxy server. Windows NT Challenge/Response authentication requires that the browser support the ‘proxy-authenticate’' HTTP header, as well as HTTP Keep-Alives to a proxy, and NT Challenge/Response. Once a user is authenticated, the user remains authenticated for the life of the TCP connection (via the Keep-Alive mechanism). Internet Explorer 3.0 supports these requirements. Previous versions do not.
The Microsoft ActiveX(tm) Software Development Kit (SDK) includes information for third parties on how to support the Windows NT Challenge/Response protocol in Web browsers, both direct to Web servers, and to proxies.
Catapult Server offers the ability to control which Internet sites are accessible to private network clients. The Proxy service server can be configured to grant access to all Internet sites except for the ones specified, or it can be configured to deny access to all Internet sites except for the ones specified. In either case, the list of sites applies to all requests issued to the Proxy service on that server. It is currently not possible to specify domain filtering on a user-level basis, although different Catapult Servers on your network can offer access to different sites, and for different users. (Also, the open, documented Internet Server API (ISAPI) provides an extensible means for third parties to provide customized filtering.)
Each entry in the grant/deny list can be an IP address, an IP subnet, or a domain name. A domain name can be a computer name (such as www.microsoft.com), or a domain name that represents multiple computers (such as microsoft.com), in which case, the entry applies to all computers in the domain.
If domain filtering is enabled, the Catapult Proxy ISAPI application verifies that each WWW, FTP, and gopher request is directed to an Internet site to which access is permitted, before issuing the request to the site. If access is not permitted, an error message is returned to the client.
If the request specifies a DNS site name, the site name is resolved to an IP address, and both the DNS name and IP address are searched for in the domain filtering site list. If a client request is received that specifies an IP address rather than a DNS name, the IP address is searched for in the domain filtering site list, and if at least one entry in the site list contains a domain name, the request's IP address is converted to a DNS name by doing a DNS reverse resolution, and the domain name is searched for in the site list.
The Catapult Server Proxy service uses caching to maintain a local copy of Web objects. This allows subsequent requests for these objects to be serviced from a local disk copy rather than issuing the request over the Internet, thereby improving user-perceived performance and reducing bandwidth consumption on the site's Internet connection.
The Catapult Server Proxy service caching provides the following features:Active caching uses the cache to proactively ensure the freshness and availability of certain HTTP data. In this mechanism, the cache manager creates its own request for an object, without client prompting, when the TTL has expired or is near expiry. Web objects are subject to active caching on the basis of their popularity relative to their rate of change. Additionally, the active caching algorithm incorporates calculations of current server load in order to “time shift” requests to the Internet from peak usage hours to off-hours.
Negative caching consists of creating cache objects that represent HTTP error conditions associated with accessing a particular URL (for example, URL not found). These responses are cached and returned for subsequent client requests for the same URL. Unavailable Server Protection maintains potentially stale data in the cache. This is used to service client requests sent to a remote server that may be temporarily inaccessible.
RWS Service FeaturesWindows Sockets is a mechanism for interprocess communication (IPC) between applications running on the same computer, or on different computers connected by a local area network (LAN) or wide area network (WAN). Windows Sockets defines a set of standard APIs that an application uses to communicate with one or more other applications, usually across a network. Windows Sockets supports initiating an outbound connection (for clients), accepting an inbound connection (for servers), sending and receiving data on those connections, and terminating the connection when done.
Remote Windows Sockets is a mechanism that makes a Windows Sockets-compatible application running on an private network perform as if it is directly connected to the Internet, when actually, there is a gateway computer connecting the two networks. The client application calls Windows Sockets APIs to communicate with an application running on an Internet computer. The RWS components remote the necessary APIs to the gateway computer, thus establishing a communication path from the internal application to the Internet application through the gateway computer. This is totally transparent to the two applications. See the following illustration
The Catapult Server Remote Windows Sockets service provides the following features:
RWS supports communication over TCP/IP and IPX/SPX on the private network. However, only applications that are written to use Windows Sockets over TCP/IP (Internet applications) can be remoted.
Supporting communication on the private network by use of the IPX/SPX transport protocol allows access to Internet sites from Internet applications on IPX/SPX networks (by using IPX/SPX communications between the client and Catapult Server). It also allows access to internal Web sites from Web browsers on IPX/SPX networks (using IPX/SPX communications between the client and Catapult Server, with Catapult Server running on same computer as the Web server).
No application support is needed. The RWS service provides Windows NT Challenge/Response authentication (secure, encrypted logon) whether or not the client application supports it. You can use Windows NT Challenge/Response authentication between RWS clients and the Catapult Server RWS service to avoid sending passwords across the internal network. Once authentication is done, the RWS service uses the logon user name to verify that the user has permission to do the network operations attempted by the application.
Authentication for an application is done one time, when the application first links to Windows Sockets (the RWS client dynamic link library (DLL)). This avoids the overhead of authentication on each network connection. Authentication is done between the RWS service and the RWS client DLL on the internal computer, regardless whether the internal application will be initiating outbound connections to the Internet or receiving inbound connections from the Internet. This means that special support on external (Internet) computers is not needed.
The Catapult Server Remote Windows Sockets (RWS) service offers client and server support for most standard and custom Internet applications that communicate by using Windows Sockets. Almost all Windows Sockets 1.1 TCP/IP applications can be remoted.
Access is controlled by port number, protocol, and user or group. Each port can be enabled or disabled for communications by a specific list of users or user groups. The list of users allowed to initiate outbound connections on a port can be a different list than the list of users allowed to listen for inbound connections on the same port. Access for TCP protocols is controlled separately from UDP protocols.
You can restrict access to remote Web sites by domain name, IP address, and subnet mask. You can choose to grant access to all Web sites except those listed, or deny access to all Web sites except those listed. The settings are global and affect all users who access the Internet through the Catapult Server.
Routing from the Internet to the private network is never allowed. (If your private network runs TCP/IP, the serverÆs Enable IP Routing check box in the Network application should not be selected. Clearing this check box prevents unauthorized IP packets from infiltrating your network. The Enable IP Routing check box is located in the Advanced Microsoft TCP/IP Configuration dialog box. Access this through the Network application in Control Panel.)
All requests to the Internet are done with the gateway server‘s Internet IP address as the source address. This hides internal IP addresses, and allows use of unregistered or private (net 10) addresses.
Each log entry contains the user name of the client and all request information including the time and date of the request, and the size of the requested objects. A new log can be created periodically. This can be daily, weekly, monthly, or when the file size reaches a preset size. The log can be maintained in a text file or in an ODBC-supported database (such as Microsoft SQL Server).
The application running on the private network must be a 16-bit or 32-bit Windows Sockets version 1.1 application running on a Windows 3.1-, Windows For Workgroups 3.11-, Windows 95-, or Windows NT-based computer. The application running on the external (Internet) network can be any TCP/IP-based application on any common operating system (such as Windows, UNIX, or Apple Macintosh).
The RWS service is administered by using Internet Service Manager, the administrative tool that is installed as part of Microsoft Internet Information Server. Property sheets for the RWS service provide a simple, intuitive administrative interface. Internet Service Manager allows management of both local and remote computers running Catapult Server.
Features of Proxy and RWS Services TogetherWhen the Proxy and Remote Windows Sockets services are used together, they can be configured so that the features of each service complement the other. If configured properly:
To implement this, the server and client are configured as follows:
The LAT defines the IP addresses that are part of the private network. The LAT is created by the Catapult Server Setup program and is stored in the Iaslat.txt file, located by default at C:\ias\clients. When a client computer runs the client Setup program, this table is downloaded from the server to the client. When an RWS client attempts to access an IP address, it uses the LAT to determine whether the address is inside the private network (and can be connected to directly) or is outside on the Internet (and therefore must be connected to through Catapult Server).
For more information about the LAT and about running the RWS and Proxy services together, see “Chapter 5, Server Configuration” and Appendix A, “Architecture.”
© 1996 by Microsoft Corporation. All rights reserved.